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Abstract: 



l^J^S^ * V '7 0nl f0r 4 new BIOS service, 
which will be known as the BIOS32 Service Directory 
He new service will provide information about those 
*™« s * me BI0S ^ callers running m 

fti^^J^c ^ BIOS 32 Service Directory will 
itself be a 32-bit BIOS service.) The expected clients of this 
service are 32-bit operating systems and 32-bit device 
drivers. The expected providers of this service are BIOS 
vendors thai implement one or more 32-bit BIOS services 
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1 Introduction 

The BIOS32 Service Directory proposal came into being during the attempts to establish 
a 32-bit code interface for the Peripheral Component Interconnect (PCI) standard. A 

°? J TfS nCedcd Mlvin « was: How docs * 3 2*it caller determine the existence 

of a 32-bit BIOS service? The drawbacks of a functional interlace (Lc, an entry point that 
control is transferred to) are clear in the case where the functional interface is non^xtant 
A recoverable method would seem to entail a search for a signature as proof that a 
functional interface does exist In fact, one of the first BIOS 32-bit services, EISA, uses 
? ?S? Ce s,gnaturt at * location in the OFOOOh segment However, as more 32- 
bit BIOS services are required and come into existence, it is obvious that providing a 
signature (and any associated information, such as entry points, segment requirements, 
etc.) for each is a costly usage of a scarce memory resource. Hence, the idea behind the 

The BIOS32 Service Directory uses a single signature to indicate the 
existence of a generic 32-bit service that returns information on ail specific 
32-bit services 

A further justification for implementing a general solution versus continuing to solve the 
problem on a case-by-case basis is seen m the obvious benefits a standard provides to the 
industry. Code reusability, modular fphig-m'-able) implementation of new 32-bit BIOS 
mterfaces, thorough specification of calling environment requirements, etc., are a few 
benefits which come to mind. 

The BIOS32 Service Directory has two components: the Header and the Calling Interface. 
The Header is a static data structure that includes the signature and which is located in a 
well-known memory range. The existence of a valid Header implies the existence of the 
Calling Interface and, in feet describes its entry point The Calling Interface is a body of 
code and data which exists in a separate memory space apart from the Header and any 
particular 32-bit BIOS services. It provides a functional interface through which a caller 
receives information about a particular 32-bit BIOS service. (Section 0 describes a 
hypothetical memory map of the Header, Calling Interface, and the "XYZ" 32-bit BIOS 
service.) 

The design of the Calling Interface is extensible in two dimensions. First, it is a function- 
based interface - future revisions of the service can incorporate new features, as they 
become necessary. Second, specific 32-bh BIOS services wfll be represented by a 4-byte 
Component ID. This will enable both OS callers and BIOS32 Service Directory 
implemcntors alike to easily add new 32-bit BIOS services as they become available. 
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Standard BIOS 32-blt Servlw Directory 

Interface to the B10S32 Service Directory, zed a summary wt»h <rrampt*5 



2 The BIOS32 Service Directory Hemder 

A BIOS which implements the B10S32 Service Directory must embed a specific, 
contiguous 16-byte pattern somewhere in the physical address range OEOOOOh - OFFFFFh. 
The pattern must be paragraph aligned (i.e., it must start on a 16-byte boundary). This 
partem is known as the BIOS32 Service Directory Header. 

The Header is comprised of six distinct fields. The following table describes each field. 
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TABLE 1: Tht BIOS32 Service Directory H«e4»r 



SXi^ii?^ Direct0 ' y shoul < 1 ^ determine <» existence by loot™ 

i£ *. si ~,.JfTT Tr" m ** fint 4 "y" 5 0' «d> paragraph. When, and 

Heade/ml^JV^f "« «** should perform a ehedcsi, of*Sl byleTfa Z 

S?ATO 5£l tSf - m "r^-il 01 ^ " 0ffi « 9^-) An byus iaT Header 
Jz Vrr" ^"ner wnh a result of Oh. If the checksum is valid then the 32-bit entrv 

n«He^ * TV* BIOS32 Service OhwSSjhSS 

platform " " f0U0d *" *' B10S32 *«*• Directory doi not eL on th. 
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Sfndird BIOS 32-blt Strrlct Directory 



3 The BIOS32 Service Directory Calling Interface 

If the BIOS32 Service Directory existence has been determined (via the Header test 
above) then the 32-bit physical address found in the Header can be used as the entry point 
to the Caning Interface. Clients should CALL FAR to this address. The client's calling 
environment has the following requirements. 



3.1 Code Segment 

The CS code segment selector must be set up with a segment descriptor with the 
following values: 

The base address must be leas than or equal to the (4kb) page address of 
the page that contains the entry point. For example, if the entry point is 
0FFF81234h men the base address must be less than or eaual to 
0FFF81000h. 

The limit must be such that the base address phis the limit generate an 
address that is greater than or equal to the last address on the (4kb) page 
which follows the page containing the entry point. For example, if the 
entry point is 0FFF81234h then the base address plus the limit must be 
greater man or equal to 0FFF82FFFh. 

Simply stated, the base address and the limit must "encompass" both the 
page that contains the entry point and the following page. 
The segment type must be 100b (code, execute only) or 101b (code, 
execute/read). However, the implementors of the Service Directory cannot 
assume read access to the CS code segment 
* The system bit must be 1 (nonsystem segment). 

It is recommended that the Descriptor Privilege Level (DPL) be 0. (The 
CS descriptor DPL becomes the Current Privilege Level, or CPL). If the 
CPL is not 0, then the OS must provide trapping and vtrtualizanon services 
for ring 0 privileged instructions (such as those that access CRx). Note 
also the dependency of mis field on the IOPL field in EFLAGS (see Section 
0). 

The Default Size bit must be 1 (32 bits). 

The B10S32 Service Directory entry point, and its associated code and data, may 
be located anywhere within the 4Gb physical address space. However, it is 
guaranteed to be physically contiguous (i.e.. it will be delivered in ROM or 
FLASH space) and to fit within two pages (i.e., it wiD not span three pages). 
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3.2 Data Segments 

Tht DS data segment selector must be set up with a segment descriptor with the 
following values: r 



The base address must be equal to the CS base address. 
The limit must be greater than or equal to the CS limit 
The segment type must be 000b (data, read only) or 001 (data, read/write). 
However, the implementors of me Service Directory cannot assume write 
access to the DS data segment 
The system bit must be 1 (nonsystem segment). 
The Descriptor Privilege Level (DPL) must be greater than or equal to 
CPL (see the DPL field in Section 0). 



There are no requirements concerning the ES, FS, and GS data segment selectors. 

3.3 Stack Segment 

The SS stack segment selector must be set up with a segment descriptor with the 
following values: 

The segment type must be 011b (data, read/write, expand-down) or 001b 
data, read/write, expand-up). 
* The system bit must be 1 (nonsystem segment). 

The Descriptor Privilege Level (DPL) must be equal to the CPL (see the 

DPL field in Section 0). 

Tht De&ult Size bit must be 1 (32 bits). 

The Granularity bit must be 1 (4Kb). 

Note mat the above settings ensure a stack size of at least 4kb. It is the caller's 
responsibility to ensure that there is at least lkb of unused stack available. 
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3.4 Paging 

Paging may or may not be enabled. If paging is enabled, then the address space 
that is described by the CS and DS selectors must be linearly contiguous. Thai is, 
the original physical contiguity of the Calling Interface as found in ROM or 
FLASH must be preserved. (The Calling Interface code and data is written to be 
position-independent and HP-relative). 



3.5 IOPL 

In order for the Calling Interface to execute I/O instructions, the I/O Privilege 
Level (IOPL) field in EFLAGS must be greater than or equal to the CPL (see the 
DPL field in Section 0). 

The BIOS32 Service Directory Calling Interface is function-based and all parameters are 
passed in registers. If a register is not specified as an output parameter for a function, 
then it will be preserved. All flags are preserved. Function values are passed as input 
parameters in register BL, Return status is passed back in register AL. A return status of 
OOh indicates that the function was successful A return status of 80h indicates that the 
requested function (in BL) is not supported Other AL return values are defined by the 
individual functions. There is currently one BIOS32 Service Directory function defined 
It is specified below. 



3 .6 The Component Existence Function (BL - Oh) 

The Component Existence function returns information about whether a specific 
32-bit BIOS service exists and, if it does, what memory space it occupies. 

Input: 

BL, Oh 

EAX, Component ED 



The Component ID is a 4-byte ASCII string which uniquely 
identifies the 32-bit BIOS service. The specifications for particular 
BIOS services define their own Component IDs. (It is important 
that those specifications define whether the Component ID string is 
packed left to right, or right to left) 
EBX, Reserved, set to Oh 
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Output: 

If requested 32-bit service does not exist 

AL = 81h 
If requested 32-bit service does exist 

AL-Oh 

EBX - base address of 32-bit BIOS service 

ECX = length of 32-bit BIOS service 

EDX = oSset (from EBX) of 32-btt BIOS service entry point 

The meaning of the EBX, ECX, and EDX registers is dependent on 
the particular 32-bit BIOS service specification. That is, they may 
represent exact values far setting up segment selectors, minimal 
"encompassing" values, etc 



3 .7 Future Functions 

Future BIOS32 Service Directory functions may be defined in subsequent revisions 
of this document The function parameter interface is not constrained to register 
passing and may employ input/output parameters on the stack. This is feasible due 
to the static definition of the stack (see Section 0). 

4 Summary 

This paper describes the BIOS32 Service Directory. It identifies 
two distinct memory components: the Header and the Calling Interface The Header is a 
paragraph of signature data located m the memory range OEOOOOh - OFFFFFL The 
Calling Interface is a body of code that occupies a physically contiguous section of 
memory anywhere in the 4Gb address space and is less than two pages (8kb) in length. 
The Header contains a pointer into the Calling Interface memory area. 

The BIOS 32 Service Directory Calling Interface functions describe additional memory 
areas that contain code and data for specific 32-bit BIOS services. A memory map for a 
hypothetical Header, Calling Interface and the "XY27* 32-bit BIOS service follows. 
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Standard BIOS 32-bit Service Directory 
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This paper provides for a standard method of accessing 32-bit BIOS 
services. The extensibility of the BIOS32 Service Directory Calling Interface may be used 
easily to advance a standard method as new 32-bit BIOS services are recognized and 
implemented. 
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»i£def TESTEXEC 
// test bios execute function. 

printf Cphadtest - test bios execution breakpoint^' ) ; 
ioExec a (PIOC.EXECl) systemBuf f er; 

ioExec->biosFunction » biosShadowAreeBaseVA ♦■ biosServiceDirtctoryVA. 
strncpy ( (PUCHAR) (tioExec->regEMC) . BIOS_PM_SIGNATORE . . 4 ) ; 
io£xec->regEBX = OL; 

if (DeviceloControl (hDriver . 
IOCTL_BIOS_EXEC, 
bufferPtr. 
256, 

bufferPtr. 
256. 

StactualXfr, 

prinSf^'IOCTL 2052 -BIOS Execute (%s) - successNn' . 

printf C» bytes returned: %U\n'. actualXfr) . 

printf ('Register contents :\n") ; .„«,. 
printf CAL = %X\n'.. <"^ b> *Sg* .* °* tm) ' 
printf CEBX = %LX\n'. ^fxeoregEBX . 

printf l-ECX » %LX\n". ^S^'^SS ' 
printf CSDX * %LX\n'. xoExec->regEDX ) . 

}else{ 

ioCode = GetLastErrorO; . TVVn . ,'• 

printf CIOCTL 2050 failed on %LX\n . loCodei . 

} 

•endif 
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// 

case IOCTL_BXOS_aCEC ; 

•ifdef DEBUGKZ 

MxIoKdPrint (41; 

♦end if 

// Function 4 « Code 2052 is 'BIOS Execute*. 

// The function executes coda la the shadow area. 

ioExecBios « (PIOC.EXEC1) (trp->AsaociatedIrp, SystemBuf f er) ; 



if (foundBio«32 mm FALSE) { // if bios32 not found in. 

ioExecBios->runStat ■ FALSE; // didn't run, 

return (loCtlFiniah (Irp, STATUS_SUCCESS , sizeof (IOC_WECD) ); 



// cheek the range of the requested function. 

actualXfrd ■ rangeChecfe (ioExecBioa->biosFunction. 

1L. 

HODE.SRADOW. 
lenBiosRom 

) ; 

// failed range check, 
if (actualXfrd »» 0) ( 

return (XoCtlFinish (Irp. STATUS .ACCESS .DENIED . sizeof (IOC.EXECD) ); 

) 



// now execute the function, 
if ( (ioExec3ios->biosFunction>«» ( (ULONC)bios32Service£ntry Point* iULONC) rojnMapP^ 
connectBios (ioExecBios. ioExecflios->biosFunction) ; 

else 

execBios (IoExecBios, xoExecBios->biosFunction) ; 

ioExeeBios->runStat « 1; 

return ( IoCtlFinish ( Irp. STATUS .SUCCESS, sizeof <IOC_EX£Cl)> ); 
// don't forget to return exec struct.. 



// function address. 
// only look at o.p. 
// read/exec mode. BIOS. 
// length of rom space. 
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* ragistar context 'and calls the 



void 

•xacaios ( 

PIOC.EXEC1 
ULONG 



systenbu£far # 
•ntrypoint 



( 

tifdaf BIOS M_ rtT.T, 

void (far •addres«32) (PIOCJXEC1); 
•else 

void (•addrea«32) (PI0C.EXEC1) ; 
iendif 

*address32 « (void (•) (PIOC.EXEC1) Jentrypoint; 



[•ystambuffar] // ptr co the systembuff 



.asm ( 



push 
push 
call 



•ax 

es 

Uddress32] 



// make it a FAR call 

// call to the Serive Directory 



(•addreas32> (systembuffer) ; 



// this is service inter 



> 
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